[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] General question



> I'm new to Xen and I read the documentation in detail.

Thanks for taking the trouble to read the docs - it's a big help!

> But sometimes, asking a question to an experienced user help to avoid
> mistake.

Yep.

> So far, I can understand that Xen gives me theses advantages:
>    - Security (one domU get hacked, the others are relatively safe)
>    - High availability (if one node die, the other node can start the
> domU and restore the service)
>    - Performance (live migration if one node is too busy)

Yep, yep, yep.

At some stage you might want to consider using the restartable driver domains 
functionality to provide robustness against driver bugs, create a virtual 
DMZ, etc but that's another issue - you probably don't want to use this if 
you're just starting out. (and I'm not sure how well restartability of device 
drivers works right now - it needs to be automated in any case).

> - To perform live migration, I need to filesystem to be present on
> both server. I would use NFS ROOT. Is it recommended? If not, what is
> the best solution (iSCSI is not an option here)? Note that the Apache
> server will have high load during the day... and the documentation
> says "Note that the Linux NFS root implementation is known to have
> stability problems under high load (this is not a Xen-specific
> problem), so this configuration may not be appropriate for critical
> servers."

You could use NBD, all you have to do is specify the NBD server in the domain 
config file - there's a script to automatically connect to an eNBD server in 
dom0.  Or you could set up iSCSI and arrange to have the block device 
available at the same device node on both systems so that the device could be 
found after migration.  Or you could use a SAN if you have the money ;-)

In all these cases, the fact that the block device is on the network is hidden 
by dom0, so the domU doesn't even need to know about it.

> - What happend with the SWAP partition during migration? If I
> understand correctly, my root filesystem is on NFS so there is no
> problem. But how handle the SWAP partition for live migration?

Either apply the swapping to NFS patches (if they're not in mainline yet) or 
provide a network block device to swap to.  I'd recommend the latter on the 
grounds that swapping to NFS is liable to have more stability problems - 
especially under high load.  That's an educated guess btw ;-)

> - "xm save" save only the CPU and memory state? It does not include
> the root fs nor swap partition?

Just the CPU and memory state.

> - I use a 3wares RAID card. I guess the dom0 needs to have custom
> kernel to support the card. Does the domU kernel also need the raid
> card module?

No.  The real block and net devices are entirely abstracted away - you can 
change the underlying devices and the domU won't know about it.

> - Bonus question :)  If I have a SSL server on Xen signed by Comodo or
> Verisign, does the certificate still valid when I migrate the domU to
> another node?

I don't see why it wouldn't be...

Oh and by the way: migration can break if the CPUs on the different machines 
have different capabilities (e.g. if the kernel booted with 3DNow 
instructions and you migrate it to a machne that doesn't have them).  If your 
machines have the same CPU it's not a problem.

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.